\section{Architecture}

On a systems level, Ringer is comprised of three separate components.
%The client, metadata server and search modules are shown with associated logic blocks in Figure \ref{ringerArch}.
%We discuss each of these in turn, and then show how we make them talk to each other.

\subsection{Client}

The Ringer client is built up from the FUSE\cite{fuse} library.
%FUSE (Filesystem in UserSpacE) is device which intercepts system calls in the kernel and re-directs them to a user level process.
%It is part of the Linux 2.6 kernel and is available as a kernel extension for several other operating systems. 
Using FUSE allows us to avoid writing any customized kernel code, but limits us to a standard block size of 4K.

FUSE sends the intercepted calls (corresponding roughly to POSIX filesystem calls like open, close, read and write) to a collection of custom callback functions, all of which are currently implemented in C++.
These callback functions rely on two sub-libraries providing local filesystem and networking capabilities.

The filesystem library details how data is stored on the client machine.
Currently, all client cached blocks are stored in a shadow directory on the local filesystem.
The filesystem library also manages the name mangling needed to turn the Ringer directory paths (discussed more in Section \ref{single-namespace}) into locally understandable paths and vice versa.

%We experimented briefly with using Berkeley DB\cite{berkeleyDB} as the backing local file-store.
%However, the data management involved for keeping our in-memory idea of what files are available synced with what files are actually stored in the DB proved unacceptably convoluted. 
%We decided that the modest improvements in space and performance possible with Berkeley DB over the local filesystem would not outweigh the complexity.

As expected from a P2P system, the networking library contains both a Ringer client and server.
The networking client is responsible for passing metadata queries on to the client's MDS and requesting data from other Ringer clients.

The networking server lives on a separate thread and handles requests from other clients for data, as well as processing metadata notifications from MDSs.

%The client's Fuse server is a stand alone object. 
%It is initialized once, and after that lives on another tread and responds to requests for blocks from other clients, as well as notifications by the MDS.

% Extensive use is made throughout Ringer of the boost library of C++ classes as well.

%The client is further divided into 

\subsection{Metadata Servers}

Unlike the client, the metadata server is entirely a user level process.
Again implemented in C++, it responds to client and search requests.

Like the client, it has both server and client classes.
Metadata objects (dubbed "rnodes") are stored in a Berkeley DB system internally.
Rnodes correspond roughly to the Unix inode, but carry additional information about leases and search tags. 

Instance data like the MDS's parents, children and attached clients are stored in memory.
When a MDS starts up, it reads a configuration file stating its parents.
Children make a network call to alert their parent of their existence, and similarly alert the parent when they are shutting down.

The MDS's search indexes are also stored in memory for simplicity, and must be rebuild each time the process restarts.
We assume that MDSs are unlikely to be frequently restarted.
If this is not the case, it would make sense to allow persistent indexes, as we expect the search indexes will take some time to be built.

\subsection{Search}

The search component is a stand alone command line executable.
The search program is a very simple client which, given a set of search keywords or a similar file (discussed further in Section \ref{search}), returns absolute Ringer path names. 
The actual heavy lifting of finding the correct path names to return is done by the MDS.

%Currently there is no communication between the local Ringer client and a local Ringer search binary.
%Two extensions we are contemplating include a currently trendy web service interface to search (easy to do since our transport is language independent) and a hookup with local indexing services such as Apple's Spotlight to find content on the whole Ringer network.